-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mitigate poison datasets in ECDSA when canonicalizing. #21
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Ivan that this isn't needed. I'm not blocking either way, but I think the spec is simpler without it since it's already covered by the dependency.
index.html
Outdated
implementations MUST detect <a data-cite="RDF-CANON#dataset-poisoning"> | ||
dataset poisoning</a> by default and abort processing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
implementations MUST detect <a data-cite="RDF-CANON#dataset-poisoning"> | |
dataset poisoning</a> by default and abort processing. | |
implementations MUST ensure that, by default, <a data-cite="RDF-CANON#dataset-poisoning"> | |
poison datasets</a> are detected and not processed. |
The current wording emphasizes the responsibility of the caller of the RDFC-1.0 algorithm. But in rdf-canon, we encourage implementers of that algorithm to abort when they detect a poison dataset. So most users would only have to check that the RDFC-10 implementation they are using has the appropriate default for them, or set the mitigation parameters. Of course, in some situations, they may need to detect poison graph themselves...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 0b489fa.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
*sigh* I didn't see the objections to merging the normative language in w3c/vc-di-eddsa#51 (review) @OR13 would you continue to object if we did an advisement instead? I agree w/ those objecting to a normative statement that is duplicative of the normative statement in RDF-CANON (but not to the level of objecting to the language given that you've said that you'd object if we don't have normative language). |
@msporny I think an advisement is probably better... If you do it as a MUST, then implementations will have to prove that they are not vulnerable to the attack... which seems like a burden for non technical implementers. |
Ok, there is a PR to do that here (which you have approved, so that's what we'll do):
I expect that we'll have a poison graph attack as one of the tests, which we might be able to justify because of the normative requirement on RDF-CANON that the non-JCS data integrity suites have. The RDF-CANON tests will definitely have a poison graph detection/abort test so as long as underlying implementations use a conforming RDF-CANON processor, they will detect poison graphs. We might want to double-check that at the Data Integrity layer just to be doubly sure that one that isn't conformant w/ that statement doesn't sneak through. |
This PR implements a new requirement to detect dataset poisoning by default in VC Data Integrity PR w3c/vc-data-integrity#128
Preview | Diff